Check database

Check/reorganise database/segments

• Description
• Functionality
• Related topics
• Technical documentation

Description

With this module the database can be technically checked completely or in parts. Besides the connections of the objects among each other, the collections are also checked (call of the ObjectStore utility osverifydb).

If no errors are detected, deleted objects can be permanently removed (reorganised) from the database in a second step. For this purpose 6 preparatory steps have to be taken before the database is internally reorganised with the ObjectStore utility oscompact and then created as a new copy with the ObjectStore utility oscopy.

If a persistent object is deleted from a ClassiX application, it is first only logically deleted, i.e. a deletion identifier is assigned and the object is registered in a separate list (garbage collection). To permanently remove a persistent object from an object-oriented database it must be ensured that no other object references this deleted object. This check is carried out using the ObjectStore utility osgc, which marks all "unreachable" objects as deletable and thus releases them for removal. An object is considered "unreachable" if it is not referenced in the database by any other object or list.

In order to make objects that have been logically deleted by a ClassiX application "unreachable", the following 6 steps have to be carried out:

1. Since logically deleted objects can also reference other logically deleted objects, the connections between these objects are cut. Connections to non-deleted objects, on the other hand, are retained. For this purpose, all logically deleted objects from their registration list (garbage collection) are run through. Deleted" are those objects that either have a deletion identification or are contained in the deletion registration list (garbage collection).
   
   The addresses of the objects from which connections were cut - i.e. which were changed - are saved in a file.
   
2. All logically deleted objects are removed from their registration list (garbage collection), the addresses of these objects are written to a file.
   
3. Call of the ObjectStore utility osgc with output of the addresses of the "unreachable" objects into a file, i. e. this run does NOT remove any objects from the database.
   
4. From the addresses from steps 2 and 3, a list of object addresses can now be determined which - although deleted - would not be removed from the database: For this purpose, the addresses that are considered "unreachable" (step 3) are removed from the addresses of all logically deleted objects (step 2). The resulting list contains only those addresses of logically deleted objects that must NOT and would NOT be removed from the database, i.e. which are still "actively" referenced by other objects in the database.
   
   This address list of logically deleted objects remaining in the database is compared with the addresses in the list from step 1: If addresses appear in both lists, connections have been cut, which must remain, otherwise a complete navigation from "active" objects would no longer be possible. These objects must be examined more closely: either the deletion is reversed, or the connection to the "active" database space is cut, or these objects are omitted in step 1.
   
   If such objects occur, it is not possible to proceed directly with the reorganisation of the database. After checking the situation and reacting accordingly, step 1 must be restarted. If such objects do not occur, the actual removal of the objects from the database can be continued with step 5.
   
5. Call the ObjectStore utility osgc again, but this time WITH removal of "unreachable" objects from the database.
   
6. Using the address list from step 2, the logically deleted objects still remaining in the database are registered again, i.e. entered in the garbage collection. If all these steps are called up in one go, it is checked whether the newly created garbage collection matches the list of remaining objects from step 4.
   
   Also for these remaining objects, it should be checked why references from "active" objects still exist.

Up to this point, objects were initially only deleted from the database. A reorganisation of the data in the database and thus a possible reduction in the size of the database is only achieved by successively calling the ObjectStore utilities oscompact and oscopy.

[
  CX_OBJECT_DICTIONARY
  CX_OBJECT_DICTIONARY_CI
  CX_OBJECT_DICTIONARY_ML
  CX_OBJECT_DICTIONARY_ML_CI
] iterate {
  FindAll(STACK) iterate {
    Call(RebuildDictionary)
  }
}

Functionality

• examination window
• Selection window

examination window

Selection window

This window is used to select the segments to be checked. The directory in which the logbooks are to be stored must also be selected. The check starts with "Start".

Related topics

• Index

Technical documentation

• Implementation
• Quality assurance
• Database test module

ClassiX® does not check the segments itself, but calls for each segment the batch file verifydb.bat, which is located in the project directory. This file delegates the work to osverifydb, an ObjectStore utility.

Database test module

Module name

verifydb.mod

Classes

-

Security

In addition to restricting access rights via the class and its data fields, the module can be restricted in its use via some of the received messages.